This  research  is  supported  by  the  Advanced  Research  Projects  Agency  under 
Contract  No.  DAHC15  67  C  0141.  Views  or  conclusions  contained  in  this  study 
should  not  be  interpreted  as  representing  the  official  opinion  or  policy  of  Rand 
or  of  ARPA. 


”*«»»*M»E»<B!i!EmsiKS6s6 'Sf~3&egSzgS%SgS£8!%8Bfall& 


DOCUMENT  CONTROL  DATA 


I.  ORIGINATING  ACT, VirY 


2o.  REPORT  SECURITY  CLASSIFICATION 

UNCLASSIFIED 


Thn  Rond  Corporation 

2b.  GROUP 

3.  REPORT  TITLE 

THE  DATA  RECONFIGURATION  SERVICE — AN  EXPERIMENT  IN  ADAPTABLE,  PROCESS  /PROCESS 
COMMUNICATION 

4,  AUTHOR(S)  (Lost  name,  first  name,  initial) 

Harslem,  E.  F. ,  J.  F.  Heafner 

5.  REPORT  DATE 

6a.  TOTAL  NO.  OF  PAGES 

6b.  NO.  OF  REFS. 

November  197], 

31 

7 

7.  CONTRACT  OR  GRANT  NO, 

8  ORIGINATOR'S  REPORT  NO. 

DAHC15  67  C  0141 

R-860-ARPA 

9o.  AVAILABILITY/LIMITATION  NOTICES 

9b.  SPONSORING  AGENCY 

DDC-A 

Advanced  Research  Projects  Agency 

10.  ABSTRACT 

x'  / 

,/W 


7^  The  nationwide  ARP  A  Network,  composed  of 
widely  separated  computers  that  vary  in 
make,  model,  size,  speed,  and  other  hard¬ 
ware  and  software  features,  was  set  up  to 
examine  the  intercommunication  problems 
that  arise  in  resource  shaving  among  dis¬ 
similar,  geographically  separate  systems. 

The  Data  Reconfiguration  Service  is  a  Net¬ 
work  experiment  involving  communication 
between  two  autonomous  but  cooperating 
processes  with  different  input/output  in¬ 
terfaces  .  A  DRS  user  defines  forms  that 
specify  the  desired  data  transformations 
in  order  for  each  process  to  receive  data 
in  an  acceptable  format.  The  two  processes 
then  communicate  as  if  they  were  directly 
connected.  The  DRS,  however,  monitors 
their  dialog  and  performs  the  user-speci¬ 
fied  transformations  on  data  passing  be¬ 
tween  them.  This  report  describes  the 
syntax  and  semantics  of  forms.  Examples 
are  given  of  simple  representative  uses  of 
the  DRS,  e.g. ,  field  insertion,  field  de¬ 
letion,  variable  length  string  processing, 
string  length  computation,  field  transposi¬ 
tion,  and  character  packing  and  unpacking. 
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SUMMARY 


The  AR?4  Network  is  composed  of  different  host  computers  at  the 
installations  of  various  ARPA  contractors  across  the  nation.  Informa¬ 
tion  flow  over  the  Network  is  governed  by  user  programs  at  the  sites. 

One  goal  of  the  Network  is  to  fundamentally  examine  the  inter¬ 
communication  problems  that  arise  in  resource  sharing  among  dissimilar 
systems.  The  Data  Reconfiguration  Service  (DRS)  is  a  Network  experiment 
directed  toward  such  an  examination.  The  experiment  involves  communica¬ 
tion  between  two  arbitrary,  but  cooperating,  processes  with  different 
input/output  interfaces. 

The  DRS  is  applied  as  follows.  A  user  defines  forms  that  specify 
the  desired  data  transformations  in  order  for  each  process  to  receive 
data  in  an  acceptable  format.  The  two  processes  then  communicate  as 
if  they  were  directly  connected.  The  DRS,  however,  monitors  their  dia¬ 
log  and  performs  the  user-specified  transformations  on  data  passing 
between  them. 


The  DRS  gets  an  input  stream  from  one  process,  reformats  the  input 
stream  according  to  a  form  describing  the  reconfiguration,  and  emits 
the  reformatted  data  as  an  output  stream  to  the  second  process.  (A  form 

associated  with  each  logical,  unidirectional  message  path  between  the 
process  pair.) 

This  report  describes  the  syntax  and  semantics  of  forms.  The  nota¬ 
tion  chosen  and  the  complexity  of  the  language  were  tailored  to  our 
current  network  needs. 

Examples  ate  given  of  simple  representative  uses  of  the  DRS ,  viz . , 
field  insertion,  field  deletion,  variable  length  string  processing, 

string  length  computation,  field  transposition,  and  character  packing 
and  unpacking.  _ _ _ 
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^LMMjETWgRK  AND  GOALS 

The  nationwide  ARPA  Network  fl-51  ,Q 

C""PUte'S  “  geographically  separated  °£  ““««  &« 

standardized  computers  (imp.)  r6.7,  ,  interconnected  by  small, 

leased  from  the  Mnmn  Th^TMr  “  “""“Nation  lines 

£“*  £°  P-  -ssa.es  among  bests.  al  "*  —d-for„ard  swit 
site,  speed,  and  other  hardware  and  “f  Vary  ln  Ml'e,  model 

distributed  and  traffic  routin  i  “  '*“*  f“C'lres'  network  it 
redundant  Network  paths.  Each  pamT^  *  **  ™a  <"• 

various  remote  resources  as  ore  relial>1>'  “'ess  such 

ities.  individual  programs  at  ZTsitlT’  ^  £a'J1- 

°£  primary  concern  are  the  f  a  contr°l  Information  flow, 
inherent  i„  the  marriage  of  aut  U”  inter“"nectlon  problems 

temP*  haS  b~"  —  to  provide  cCtir1^  ^  “***“-  E°  at‘ 
fM’  £~  larse  Programs  r  *"  —  -ans- 

goal  is  to  discover  and  valid  t  reSO“r<:a 

and  easy  access  to  ail  available  res  *  eChnlq“eS  Pe™itti„g  uniform 
dissimilarities,  More  »£  b”dware  and 

“  easily  accessible  as  local  ones  with  ^  SarVl“S  sh*d  be 

overall  Performance.  Mother  yoal’is  t„  “  /  ia 

USe  °£  cramming  languages:  accused  B°re  the 

compatible  languages  allowing  program  tr^Un^  ^ 

JUCh  a  network  has  many  uses  0f  *  V  3re  not  refluired. 

•those  that  readily  allow  emploracion^^  lntereSt’  *-•«.  « 
different  systems.  One  8„oh  generic  ”  ™‘a“°a  ^  among 
data  are  transmitted  to  a  remote  PTO£'™  ahariW  in  »hich 

o»er  is  ^  ln  -suits  are  returned.  iAn- 

"itced  to — —  ara 


transmission  and  data  mana^rrys^"^0'""8^^  ft<»»  f 

ys  terns ,  to  program/terminal  coupli, 
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to  a  remote  service.  For  example,  weather  modeling  programs  will  run 
on  the  ILLIAC  IV,  using  parameters  transmitted  from  Rand;  results  will 
be  returned  and  reconfigured  for  graphical  display  and  analysis.  Al¬ 
though  some  of  these  programs  exist  today,  their  Network  and  graphical 
interfaces  do  not.  Several  remote  job  entry  systems  are  now  available 
on  the  Network  (i.e.,  UCSB  and  UCLA),  yet  minimal  changes  were  made  to 
those  systems,  so  that  their  data  input/output  (I/O)  formats  differ 
considerably.  At  MIT,  the  special  Evans  and  Sutherland  graphic  hard¬ 
ware  is  offered  as  a  remote  service.  It  is  desirable  to  use  this 

service  from  such  various  kinds  of  graphics  terminals  as  the  IMLAC  and 
ARDS. 

To  further  amplify  the  problem  of  different  software  interfaces, 
many  sites  will  have  a  minimal  host  configuration  that  will  restrict 
their  data  reformatting  capabilities,  but  that  should  not  restrict 
their  access  to  remote  resources  requiring  different  formats. 

Examining  the  currently  proposed  and  existing  services,  the  kinds 
of  data  manipulations  most  frequently  encountered  are  character  set 
conversions,  prefacing  and  stripping  leaders  of  messages,  packing  and 
unpacking  repeated  symbol  strings,  generating  message  counters  and 
flags  to  be  inserted  into  the  data  stream,  graphic  device  code  conver¬ 
sions,  data  field-transposition,  and  reformatting  files. 

This  report  discusses  one  recent  approach  for  providing  the  above 
kinds  of  data  transformations  in  a  way  that  is  transparent  to  the  ter- 
minals  and  programs  involved. 

•  ^  •>  •  .  j  <:  -  •■■  ■.  rr  \T.\.  J"r  ft;//  j.}  '  ' 

THE  DATA  RECONFIGURATION  SERVICE  (DRS)  APPROACH  ... 

Application  programs,  require  specific  I/O  data  formats  that  differ 
from  program  to  program;  i  One  approach  recently  adopted  for  providing 
resource  sharing  of  disparate  programs  is  to  develop  specific  dialogs 
for  classes  of  programs.  Each  such  program  must  then  be  retrofitted 
with  one  of  the  standard  dialog  interfaces.  The  DRS  exhibits  a  dif¬ 
ferent  view  of  coupling  variegated  processes  and  terminals.  The  pre¬ 
mise  underlying  DRS  is  that  the  Network  should  adapt  to  the  individual 

Evans  &  Sutherland  Computer  Corporation,  3  Research  Road,  Salt 
Lake  City,  U*-ah  84112. 


program  requirements,  rather  than  changing  each  program  to  comply  with 
a  standard.  This  position  does  not  preclude  the  use  of  standards  that 
describe  the  formats  of  Network  message  contents;  it  is  merely  an  inter¬ 
pretation  of  a  standard  as  a  desirable  mode  of  operation,  but  not  a 
necessary  one. 

In  addition  to  differing  program  requirements,  a  format  mismatch 
occurs  when  users  wish  to  employ  many  different  kinds  of  consoles  to 
attach  to  a  single  remote  service  program.  It  is  likewise  desirable  to 
have  the  Network  adapt  to  individual  console  configurations,  rather  than 
requiring  unique  software  packages  for  each  console  transformation. 

One  approach  to  providing  adaptation  is  for  those  sites  with  sub¬ 
stantial  computing  power  to  offer  a .data  reconfiguration  service; -this 
report  describes  such  a  service,  the  DRS*  currently  being  implemented 
at  MIT,  UCLA,  UCSB,  and  The  Rand  Corporation.  The  University  of  Ill¬ 
inois,  MITRE,  and  others  will  experiment  with  its  use. 

The  envisioned  modus  operandi  of  the  service  involves  an  applica- 
tions  programmer,  who  defines  forme  that  describe  data  reconfigurations. 
The  service  stores  the  forms  by  name)  ^^(o^dd lately 

thereafter),  a  user  (perhaps  a  non-programmer)  employs  the Service  to 
accomplish  a  particular  transformation  of  a  Network  data  stream  passing 
between  a  using  process  and  a  serving  process.  He  accomplishes  this  by 

calling  the  form  by  name  and  identifying  it  with  the  using  and  serving 
processes.'- 

The  DRS  attempts  to  provide  a  notation  for  form  definition  tailored 
t0  S°me  Speclfically  need8d  instances  of  data  reformatting.  At  the  same 
time,  the  DRS  keeps  the  notation  and  its  underlying  implementation  within 
some  utility  range  that  is  bounded  on  the  lower  end  by  a  notation  expres¬ 
sive  enough  to  make  the  experimental  service  iiseful,  and  on  the  'upper  end 
by  a  notation  that  is  just  short  of  a  general-purpose  programming  language. 


II.  OVERVIEW  OF  THE  DATA  RECONFIGURATION  SERVICE 


ELEMENTS  OF  THE  DATA  RECONFIGURATION  SERVICE 

An  implementation  of  the  DRS  includes  a  module  for  Network  connec¬ 
tion  protocols  to  establish  logical  message  paths  between  the'end 
processes  that  wish  to  pass  data.  It  also  includes  a  module  (the  Form 
Machine)  to  accept  and  apply  the  definitions  of  data  reconfigurations 
(forms).  Lastly,  a  file  management  module  exists  for  saving  and  re¬ 
trieving  forms.  i  >  >  ~  -  -iv. 

This  section  highlights  connections  and  requests.  Section  III 
details  the  Form  Machine  language.  File  storage  is  not  described  be¬ 
cause  it  is  transparent  to  the  user  and  its  implementation  is  different 
at  each  DRS  host.  > 


NETWORK  CONNECTIONS  :  s 

There  are  three  kinds  of  Network  connections  to  the  DRS  (sie  Fig.  1) 

1.  .The  control  connection  (CC) r.  between  an  originating  user  and 

the  DRS.  It  is  instigated  by  the  user  to  define  forms  and  to 
request  the  user  connection  (UC)  and  the  server,  connection 
(SC),  along  with  the  application  of  form(s)  to  data  passing 
.  between  UC  and  SC. 

2.  The  UC,  between  a  user  process  and  the  DRS.  It  is  estab- 

^7  the  DRS  at  the  request  , of  the  originating  user. 

3.  The  SC,  between  the  DRS  and  the  serving  process.  It,  too, 
is  established  by  the  DRS  at  .the  request,  of  the  -originating 


The  user  process  behaves  as  if  it  were  connected  directly  to  the 

v  ,  ..:ib  {a, 

server  process ,  and  vice-  versa .  The  DRS  appears  transparent  to  both 
processes-;  its  function  is  to  reconfigure  data  that  pass  in  each 
direction  between  them  into  formats  amenable  to  each  of  their  proces¬ 
sing  requirements.  Because  the  goal  is  to  adapt  the  Network  to  user 
and  server  processes,  minimal  requirements  are  imposed  on  the  UC  and  SC. 


ORIGINATING 

USER 


CC — a  duplex  connection 
using  a  standard  Network 
protocol 


DATA 

RECONFIGURATION 

SERVICE 
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Fig.  1--DRS  Network  Connections 
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REQUESTS  OVER  THE  CONTROL  CONNECTION 


Over  a  control  connection,  the  dialog  is  directly  between  an 
originating  user  and  the  DRS,  where  the  user  defines  forms  or  assigns 
predefined  forms  to  connections  for  reformatting.  Messages  sent  over 
a  control  connection  are  formatted  according  to  a  Network  standard. 

When  an  originating  user  connects  to  DRS,  he  supplies  an  identi¬ 
fier  as  a  qualifier  to  guarantee  uniqueness  of  his  form  names.  The 
user  can  request  the  following  operations: 

1.  Accept  a  form  definition; 

2.  Purge  a  form  definition; 

3.  List  qualified  form  names; 

4.  List  the  source  text  of  a  form; 

5.  Make  a  simplex  or  duplex  logical  connection  between  a  user 
and  a  server  process.  The  connection  can  be  made  in  several 
ways,  i.e.,  with  or  without. a  Network  standard  connection 
protocol; 

6.  Abort  a  user/server  connection. 

t 

When  a  user/server  connection  is  severed  either  by  the  processes 
themselves  or  by  an  abort  request,  the  DRS  sends  an  appropriate  return 
code  to  the  originating  user. 


-7- 

III.  THE  FORM  MACHINE 

I/O  STREAMS  AND  FORMS 

This  section  describes  the  syntax  and  semantics  of  forms  that 
specify  the  data  reconfigurations.  ■  The  Form  Machine  receives  an  input 
stream,  reformats  it  according  to  a  form  describing  the  reconfiguration, 
and  emits  the  reformatted  data  as  an  output  stream. 

It  is  helpful  to  envision  the  application  of  a  form  to  the  data 
stream,  as  depicted  in  Fig.  2..  An  input  stream  pointer  identifies  the 
position  of  data  (in  the  input  stream)  being  analyzed,  at  any  given 
time,  by  a  part  of  the  form.  Likewise,  an  output  stream  pointer  lo¬ 
cates  data  emitted  in  the  output  stream. 


AA 


INPUT 

STREAM 


nA 


FORM 


CURRENT) 
POINTER  I 


CURRENT  PART  OF 


FORM  SEING  APPLIED 


|  CURRENT _ 

l  POINTER 


OUTPUT 

STREAM 


KaI 


Fig.  2— Application  of  Form  to  Data  Streams 
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form  machine  syntax^ 

form 

{rule}? 

rule 

1  i  l 

::=  (iNTEGER)o  {terms}0  {:terms)o  ; 

terms 

: :  =  term  {.term}? 

term 

. identifier  |  {identifier}0  descriptor  |  comparator 

descriptor 

• ({replicationexpr}o  >  datatype  ,  {concatexpr}o  . 
{arithmeticexpr}0  {:options}0) 

comparator 

(concatexpr  connective  concatexpr  {:options}o)  j 
(identifier  •.<=•  concatexpr  {:options}0) 

connective 

:••=  .LE.  |  .LT.  [  .GE.  I  .GT.  |  .EQ.  |  .NE. 

replicationexpr 

!!=  ft  \  arithmeticexpr 

datatype 

B  }  0  J  X  |  E  I  A  |  ED  J  AD  J  SB  |  T(ideritifier) 

concatexpr 

value |  {||  value}? 

value 

: !=  literal  |  arithmeticexpr 

arithmeticexpr 

: :=  primary  {operator  primary}? 

operator 

+|-|*|/ 

primary 

::=  identifier  |  L(identifier)  | 

V(identifier)  |  INTEGER 

literal 

2  5  6 

::=  literal type  "{CHARACTER}  0  " 

literal type 

••••=  '  B  |  0  |  X  |  A  j  E  |  ED  |  AD  |  SB 

options 

::=  ,  sfur  (arithmeticexpr)  | 

sfur  (arithmeticexpr)  ,  sfur  (arithmeticexpr) 

sfur 

S  |  F  |  U  |  SR  j  FR  |  UR 

identifier 

::=  ALPHABETIC  {ALPHAMERIC }q 

T 

These  syntactic  statements  are  referred  to  in  the  following 
semantic  descriptions.  6 


FORMS 
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-9- 


A  form  is  an  ordered  set  of  rules. 

form  ::=  {rule}” 

The  current  rule  is  applied  to  the  current  position  of  the  input 
stream.  If  the  rule  fails  to  correctly  describe  the  current  input, 
then  another  rule  is  made  current  and  applied  to  the  input  stream.^* 

The  next  rule  to  be  made  current  is  either  explicitly  specified  by  the 
current  term  in  the  current  rule  or  it  is  the  next  sequential  rule  by 
default. 

If  the  current  input  stream  is  correctly  described,  then  some 
data  may  be  emitted  at  the  current  position  in  the  outpuc  stream 
according  to  the  rule.  The  input  and  output  stream  pointers  are  ad¬ 
vanced  over  the  described  and  emitted  data,  respectively;  the  next 
rule  is  applied  to  the  now  current  position  of  the  input  stream. 

Application  of  the  form  is  terminated  when  an  explicit  return, 
e.g.,  UR  (arithmetic  expression)  is  encountered  in  a  rule.  The  user 
and  server  connections  are  closed  and  the  evaluated  return  code  (arith¬ 
metic  expression)  is  sent  to  the  originating  user. 

RULES 

A  rule  is  a  replacement,  comparison,  and/or  an  assignment  opera¬ 
tion  of  the  form  shown  below. 

l  l  .1 

rule  : :=  {lNTEGER)o  (termslo  {;terms)o  ; 

.1^  '■ 

The  optional  integer  (rule  name)  exists  so  that  the  rule  may  be 
referenced  elsewhere  in  the,  form  for  explicit  rule  transfer  of  control. 
Integers  are  in  the  range  0  ^  INTEGER  £  9999.  Rules  need  not  be  named 
in  ascending  numerical  order. 


T 

If  only  a  part  of  the  rule  succeeds,  the  input  pointer  is  not 
advanced. 


( 
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TERMS 

The  input  stream  is  described  by  zero  or  more  terms, 

1 

{ terms }o 


and  the  output  stream  is  described  by  zero  or  more  terms, 

1  1 

{  ;  terms}o  / 


where 


terms  ::=  term  {,term}“  . 

Terms  are  expressed  in  one  of  the  formats  indicated  below. 

.1-  .  .  ‘  „•  s  ,  t  . 

term  identifier  |  {identif ier}0  descriptor  (comparator 

Term  Format  1 

The  first  term  format,  identifier ,  is  a  symbolic  reference  to  a 
previously  identified  term  (term  format  2,  below)  in  the  form.  It  takes 
on  the  same  attributes  (replication,  type,  value,  length)  as  the  term 
by  that  name  and  is  normally  used  to  emit  data. 


Term  Format  2 

The  second  term  format,  {identifier}!  descriptor,  is  used  to  collect 
input  or  to  emit  output. 


descriptor  ::=  ({replicationexpr}0  ,  datatype  ,  {concatexpr}!  , 
(arithmeticexpr}o :options}o) 

The  above  five  descriptor  elements1  correspond  to  the  attributes  re¬ 
plication,  data  type,  value,  length,  and  transfer  of  control,  respectively 


See  the  IBM  System  Reference  Library  Form  C28-6514  for  a  similar 
interpretation  of  the  pseudo  instruction.  Define  Constant,  after  which 
the  descriptor  was  modeled. 
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The  replicationexpr ,  if  specified,  causes  the  unit  value  of  the 
term  to  be  repeated  the  number  of  times  indicated  by  the  replication 
expression's  value.  The  unit  value  of  the  term  (quantity  to  be  repli¬ 
cated)  is  determined  from  the  composite  of  data  type,  value  expression, 
and  length  expression  attributes.  The  data  type  defines  the  kind  of 
data  being  specified.  The  value  expression  specifies  a  nominal  value 
that  is  augmented  by  the  other  term  attributes.  The  length  expression 
determines  the  unit  length  of  the  term. 

The  terminal  symbol  #  in  a  replication  expression  means  an  arbi¬ 
trary  replication  factor.  It  is  explicitly  terminated  by  a  non-match 
to  the  input  stream.  Termination  may  result  from  exceeding  the  256- 
character  limit. 

A  null  replication  expression  has  a  default  value  of  one.  Arith¬ 
metic  expressions  are  evaluated  from  left-to-right  with  no  precedence. 


The  L(idencifier)  is  a  length  operator  that  generates  a  32-bit 


binary  integer  corresponding  to  the  length  of 

the  term  named.  The 

V(identifier)  is  a 

Value  operator  that  generates  a  32-bit  binary  inte- 

ger  corresponding 

to  the  value  of  the  term  named.  The  T(identifier)  is 

a  type  operator  that  generates  a  type-code,  for 

the  term  named. 

The  data  type 

describes  the  kind  of  data 

that  the  term  represents. 

Data  Type 

Meaning 

Unit  Length 

B 

Bit  string 

1  bit 

0 

Bit  string 

3  bits 

X 

Bit  string 

4  bits 

E 

EBCDIC  character 

8  bits 

A 

Network  ASCII  character 

8  bits 

AD 

ASCII  encoded  decimal 

8  bits 

ED 

EBCDIC  encoded  decimal 

8  bits 

SB 

Signed  binary 

1  bit 

The  value  expression  is  the  nominal  value  of  a  term  expressed  in 
the  format  indicated  by  the  data  type.  It  is  repeated  according  to  the 


It  is  expected  that  such  additional  data  types  as  floating-point 
and  user-defined  types  will  be  added  as  needed. 


replication  expression.  A  null  value  expression  in  an  input  term 
defaults  to  the  data  present  in  the  input  stream  and  generates  padding 
in  the  output  stream  according  to  the  restrictions  and  interpretations 
stated  later.  The  input  data  must  comply  with  the  data  type  attribute, 
however . 

The  length  expression  states  the  length  of  the  field  containing 
the  nominal  value.  If  the  length  expression  is  less  than  or  equal  to 
zero,  the  term  succeeds,  but  the  appropriate  stream  pointer  is  not  ad¬ 
vanced.  Positive  lengths  cause  the  appropriate  stream  pointer  to  be 
advanced  if  the  term  otherwise  succeeds. 

Options  is  defined  under  Term  and  Rule  Sequencing. 

Term  Format  3 

The  third  term  format  is  used  for  assignment  and  comparison. 

comparator  (concatexpr  connective  concatexpr  (:options}0)  | 

(identifier  •<=>•  concatexpr  {:options)o) 

The  assignment  operator  •<=•  assigns  the  value  to  the  identifier. 
The  connectives  have  their  usual  meanings.  Values  to  be  compared  must 
have  the  same  type  and  length  attributes  or  an  error  condition  arises 
and  the  form  fails. 

The  Application  of  a  Term 

The  elements  of  a  term  are  applied  by  the  following  sequence  of 
steps. 

1.  The  data  type  (datatype),  value  expression  (concatexpr),  and 
length  expression  (arithmeticexpr)  together  specify  a  unit 
value,  x. 

2.  The  replication  expression  (replicationexpr)  specifies  the 
number  of  times  x  is  to  be  repeated.  The  value  of  the  con¬ 
catenated  x's  becomes  y  of  length  L. 

3.  If  the  term  is  an  input  stream  term,  then  the  value  of  y  of 
length  L  is  tested  with  the  input  value  beginning  at  the 
current  input  pointer  position. 


4. 


If  the  input  value  satisfies  the  constraints  of  y  over  length 

L,  then  the  input  value  of  length  L  becomes  the  value  of  the 
term* 

In  an  output  stream  term,  the  procedure  is  the  same,  except  that 
the  source  of  input  is  the  value  of  the  term(s)  named  in  the  value  ex¬ 
pression  and  the  data  is  emitted, in  the  output  stream. 

The  above  procedure  is  modified  to  include  a  one-term  look-ahead 
where  replicated  values  are  of  indefinite  length  because  of  the  arbi¬ 
trary  symbol  it. 


Restrictions  and  Interpretations  of  Term  F.mrMnne 


1.  Terms  having  Indefinite  lengths  because  their  values  are  re¬ 
peated  according  to  the  #  symbol,  must  be  separated  by  some 
type-specific  data,  such  as  a  literal.^ 

2.  Truncation  and  padding  include: 

a.  Character-to-character  (A  «-*•  E)  conversion,  which  is  left- 
justified  and  truncated  or  padded  on  the  right  with  blanks; 

b.  Character-to-numeric  and  numeric-to-numeric  conversions, 
which  are  right- justified  and  truncated  or  padded  on  the 
left  with  zeros; 

c.  Numeric-to-character  conversion,  which  is  right-justified 
and  left— padded  with  blanks. 

3.  The  following  are  ignored  in  a  form  definition  over  the  con¬ 
trol  connection. 

a.  Control  characters . 

b.  Blanks,  except  within  quotes. 

c.  /*  string  */  is  treated  as  comments,  except  within  quotes. 

4.  The  following  defaults  prevail  where  one  of  the  fields  in  a 
term  is  omitted. 

a.  The  replication  expression  defaults  to  one. 

b.  it  in  an  output  stream  term  defaults  to  one. 


number^of^ASCTT  ‘h  ‘1°t  s'>eclficall>'  required,  however.  An  arbitrary 
number  of  ASCII  charactera  could  be  terminated  by  a  non-ASCII  character 


c.  The  value  expression  of  an  input  stream  term  defaults  to 
the  value  found  in  the  input  stream,  but  the  input  stream 
must  conform  to  data  type  and  length  expression.  The 

value  expression  of  an  output  stream  term  defaults  to 
padding  only. 

d.  The  length  expression  defaults  to  the  size  of  the  quantity 
determined  by  the  data  type  and  value  expression. 

e.  Control  defaults  to  the  next  sequential  term,  if  a  term  is 
successfully  applied;  otherwise,  control  defaults  to  the 
next  sequential  rule. 

5.  Arithmetic  expressions  are  evaluated  left-to-right  with  no 

precedence.  '<  f 

6.  The  following  limits  prevail.* 


a.  Binary  lengths  are  £  32  bits. 


b.  Character  strings  are  *  256  8-bit  characters. 

c.  Identifier  names  are  4  characters. 

d.  Maximum  number  of  identifiers  is  £  256. 

e.  Label  integers  are  ^  0  and  £  9999. 


7.  Value  and  length  operator  produce  32-bit  binary  integers. 

The  value  operator  is  currently  intended  for  converting  A  or 
E  type  decimal  character  strings  to  their  binary  correspondents. 
For  example,  the  value  of  E'12*  would  be  0. ...  ..01100.  The 
value  of  E'AB'  would  cause  the  form  to  fail. 

TERM  AND  RULE  SEQUENCING 

Rule  sequencing  may  be  explicitly  controlled  by  using 

S£Z  ■  .  1  l$\:.  :i: 

l JoptionsJo  »  . 

defined  as 


options  : := 


sfur  (arithmeticexpr)  i| 
sfur(arithmeticexpr)  ,  sfur(arithmeticexpr) 


sfur 


:=*  S  I  F  I  U  I  SR  I  FT?  I  in> 


respectively.  The  arithmetic  expression  evaluates  to  an  integer; 
thus,  transfer  can  be  effected  from  within  a  rule  (at  the  end  of  a 
term)  to  the  beginning  of  another  rule.  R  means  terminate . the  for 

and  return  the  evaluated  expression  to  the  initiator  over  the  cont 
connection. 

If  terms  are  not  explicitly  sequenced ,  .  the  following  defaults 
prevail : 


1.  When  a  term  fails,  go. to  the  next  sequential  rule. 

2.  When  a  term  succeeds,  go  to  the  next  sequential  term  with! 
the  rule. 

3.  At  the  end  of  a  rule,  go  to  the  next  sequential  rule. 

In  the  following  example,  note  the  correlation  between  transfe 
of  control  and  movement  of  the  input  pointer. 
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IV.  EXAMPLES 


The  following  examples  (forms  and  also  single  rules)  are  simple 
representative  uses  of  the  Form  Machine. 


FIELD  INSERTION 


To  insert  a  field,  separate  the  input  into  the  two  terms  to  allow 
the  inserted  field  between  them.  For  example,  if  the  input  stream  con- 
tains  pairs  of  numbers  encoded  as  ASCII,  separated  by  a  slash  (i.e., 
123/456/...),  the  following  form  labels  them  as  x,  y  pairs  separated 
by  a  line  feed,  and  a  carriage  return  (i.e.,  X=123/Y=456  @  @...). 


1  XVAL  (#,A,  ,1) ,  (,A,A"/",1),YVAL  (#,A,  ,1)  ,  (,A,A"/M) 
/*pick  up  the  x  as  XVAL  and  y  as  YVAL  */ 

2  :  (»A,A"X=",2),XVAL,(,A,"/Y“",3),YVAL  ; 

/*emit  the  labels  followed  by  the  values  of  x,  y  */ 


3  .  :  ( »X,X"OAOD"  ,4:  U(l))  ; 

/*emit  the  .line  feed,  carriage  return  and  loop  back  for  the 
next  pair  */ 

DELETION 

Data  to  be  deleted  should  be  isolated  as  separate  terms  on  the, 
left  in  order  to  be  omitted  (by  not  emitting  them)  on  the  right. 


C.B,,8), 
SAVE(,A, ,10) 


/*isolate  8  bits  to  ignore*/ 

/♦extract  10  ASCII  characters  from 
input  stream*/ 


s  ( » E , SAVE , ) ; 


/♦emit  the  characters  in  SAVE  as 
EBCDIC  characters  whose  length 
defaults  to  the  length  of  SAVE 
(i.e.,  10),  and  advance  to  the 
next  rule*/ 
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In  the  above  example,  if  either  Input  stream  term  falls 
sequential  rule  is  applied. 


the  next 


VARIABLE  LENGTH  RHCnpng 


Some  devices,  terminals,  and 
records.  The  following  rule  picks 
and  translates  them  to  ASCII. 


programs  generate  variable  length 
up  variable  length  EBCDIC  records 


CHAR(#,E,,1), 


(,X,X"FF",2) 


: (>a,char,) , 
(,X,X"0D",2); 


/*pick  up  all  (an  arbitrary  number  of) 
legal  EBCDIC  characters  in  thy  input 
stream*/ 

/*followed  by  a  hexadecimal  literal, 

FF  (terminal  signal)*/ 

/*emit  them  as  ASCII*/ 

/*emit  an  ASCII  carriage  return*/ 


STRING  LENGTH  COMPUTATION 


It  Is  often  necessary  to  prefix  a  length  field 
long  character  string.  The  follouing  rule  prefixes 
with  a  one-byte  length  field. 


to  an  arbitrarily 
an  EBCDIC  3 t ring 


Q(M,,i), 

TS(,X,XmFF",2) 

'•  (»B,L(Q)+2, 8) , 


Q. 

TS; 


/*pick  up  all  legal  EBCDIC  characters*/ 

/*followed  by  a  hexadecimal  literal,  FF*/ 

/*emit  the  length  of  the  characters  plus 
the  length  of  the  literal  plus  the  length 
of  the  count  field  itself,  in  an  8-bit 
field*/ 

*/emit  the  characters  */ 

*/emit  the  terminal*/ 


TRANSPOSITION 


.It  is  often  desirable  to  reorder  fields,  such  as 
example. 


the  following 


Q(,E,,20),  R(,E, ,10) 


.  S(,E,,15),  T(,E, ,5) 


R.  T,  S,  Q; 


The  terms  are  emitted  in  a  different  order. 


CHARACTER  PACKING  AND  UNPACKING 

In  system  such  an  HASP,  repeated  sequences  of  characters  are 
packed  into  a  count  followed  by  the  character  for  wore  efficient 

storage  end  transmission.  The  first  form  packs  multiple  characters 
and  the  second  unpacks  them. 


■  /*form  to  pack  EBCDIC  streams*/ 

/*returns  99  if  OK,  input  exhausted*/ 

/*look  for  terminal  signal  FF  which  is  not  a  legal  EBCDIC*/ 
/^duplication  dount  must  be  0-254*/ 

I  (,X,X"FF",2  :  SR(99))  ; 

/*pick  up  an  EBCDIC  char/* 

CHAR(,E,  ,1)  ;  •  ,  ■ 

/*get  identical  EBCDIC  chars/* 

LEN(#,E,CHAR,1)  \ 

/*emit  the  count  and  the  char/* 
s  (SB,L(LEN)+1,8) ,  CHAR,  < :U(1) ) ; 

/*end  of  form*/ 


-19- 


/*form  to  unpack  EBCDIC  streams*/ 

/*look  for  terminal*/ 

1  (,X,X"FF",2  :  SR(99) )  ; 

/*emit  character  the  number  of  times  indicated*/ 
/* by  the  count,  in  a  field  the  length  indicated*/ 
/* by  the  counter  contents*/ 

CNT( ,B, ,8) ,  CHAR(,E, ,1)  :  (CNT,E,CHAR,1:U(1)) ; 

/*f allure  of  form*/ 

( :UR(98)) 
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